The World-Wide Web is a multimedia information space. This means that one of the design issues is dealing with various data formats. In addition to HTML and other textual formats, since the widespread availability of NCSA Mosaic and other visual interfaces to the web, more and more of the web's information is represented or augmented with data in any number of popular graphics formats.
On the web, images may be represented in many different formats. Clients vary as to the set of formats they support, and servers vary in the formats which they provide. The data is transferred in whatever seems to be the "best" format which the client and server have in common.
This mechanism that allows the web to accommodate different data formats over time is format negotiation. See also: HTTP and the specification of Content Negotiation.
The web standards do not specify a graphics format you must use.
In practice, the graphics formats you provide will be influenced by the availability in clients, the data size (and therefore transfer time), the image quality, and whether transparency is available, and whether the format is an open standard or a commercial one subject to copyright or patent fees.
Clearly, it is useful to have a lingua franca so that you know that if you support that, you will be able to read from or supply to anyone. For hypertext, HTML is mandated to be supported by all WWW clients, but for graphics there is no equivalent. Until December 1994, GIF played that role, but at that time Unisys's pursuit of patent license fees moved it from an open standard into the proprietary domain. The following pointers are made available to help developers and information providers make appropriate choices.
The typical "web page" today consists of an HTML document and some GIF images, linked via the IMG element. This is the most widely supported compound document structure, but it is by no means the only one possible. Others include:
If you want to put an image on the web in some format other than GIF, JPEG, and the other popular "inline" graphics formats -- CGM for example -- here's what I'd suggest:
Content-Type: image/x-cgm
<A href="image"><img src="image-thumbnail"></A>
In general, use IMG only for inessential, decorative images. For essential images, use the A element. That way, the consumer can at least download the image and save it to a file for later processing.
The IMG element is somewhat limited in its expressive capability. The FIG proposal is intended to be a complete mechanism for figures and similar compound document structures.
Here is a summary of just a few of the raster (bitmap) graphics formats around.
Graphics Interchange Format is a commercial format which is widely used on the web. At the end of December 1994, Unisys announced that they would be suing for patent fees for all developers of GIF software, because of GIF's use of proprietary LZW compression. GIF is a proprietary specification of Compuserve Information Services. Here are some statements on the subject:
GIF had been used very extensively and is available (Dec 94)
in all browsers which can handle graphics.
It allows 1 bit transparency (a pixel is either transparent or opaque).
It allows a palette of a maximum of 256 colors, so representation
of 24 bit color images in GIF involves loss.
Here are the
GIF-87 specifications and the
GIF-89a specs.
The JPEG (Joint Photographic Experts Group) standard is an excellent standard for most realistic images (photos for example, but not line drawings or logos). It uses a powerful, though nominally "lossy", compression method. JPEG is best suited for truecolor original images; avoid using it on images that have already been forced into a 256-color palette.
Using JPEG for a photographic image for example can produce 10:1 savings compared to GIF, as well as permitting much better display quality on truecolor-capable displays. Netscape handles inline JPEG; most older browsers need to use an external JPEG viewer.
The particular format usually used for JPEG-compressed images on the Web is JFIF. This is distinct from a JPEG compressed PICT file, which is often referred to as 'a JPEG file' on the Macintosh platform. A newer format called SPIFF is under development; when released, it is expected to be compatible with JFIF readers.
Although the "baseline" variety of JPEG is believed patent-free, there are many patents associated with some optional features of JPEG, namely arithmetic coding and hierarchical storage. For this reason, these optional features are never used on the Web.
(Previously known as: PBF, Portable Bitmap Format.)
A new zero loss proposal by Thomas Boutell, which uses LZ77 compression, is alleged to be patent-free and to be put into the public domain. A deliberate replacement for GIF, PNG contains a number of enhancements. It allows true color, including an opacity channel. Features Tom has been encouraged to include include gamma value statement, hypertext links, and progressive resolution.
See our Overview of PNG.
TIFF, "Tagged Interchange File Format" suffers from its extensibility: there are extensions to TIFF that it is not easy to know what application will accept what TIFF file.
Including graphics metafiles, vector graphics, page description, ...
Postscript is another proprietary format. However, use of the Postscript standard is free, and free software such as ghostview and Ghostscript is available to display it. Postscript is a Turing-complete reverse polish programming language with drawing primitives based on Bezier curves. It can be extremely compact for drawings. For bitmaps, however, it has a hopelessly verbose format.
Postscript has the advantage that almost all applications can produce it, as it is a common printer command language. However, often the postscript produced by applications has a lot of unoptimized header macro definition which can lead to enormous files. Another problem is that the exact definition of what should be in a postscript file for interchange is not defined. Browsers such as Midas allow postscript for embedded images.
This is an international standard for computer graphics metafiles:
need to move this into CERN HTTP doc -- connolly
The CERN HTTPD server allows images to be stored in several formats. For example, this allows a browser equipped with JPEG to get a faster copy of a file than a browser which only has GIF.
To set this up, make sure that the server knows (from the httpd.conf configuration file "Suffix" entries, or from the pre-compiled HTSInit.c) how to associate file extensions on your machine with the MIME type labels.
You can weight the quality of each type so that for example your server will preferentially send JPEG instead of GIF.
You could of course write a CGI script to automatically generate and cache alternative representations of your files.
Map *.gif /translate/*.gif Exec /translate/* /usr/local/cgi/translate
See the CERN HTTPD manual for how to create ISMAP clickable images, etc.